home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / rec / games / mud-faq / part3 < prev    next >
Text File  |  1994-04-15  |  9KB  |  161 lines
  1. Newsgroups: rec.games.mud.announce,rec.games.mud.misc,news.answers,rec.answers
  2. Path: bloom-beacon.mit.edu!hookup!swrinde!cs.utexas.edu!convex!convex!constellation!hardy.math.okstate.edu!jds
  3. From: jds@math.okstate.edu (Jennifer "Moira" Smith)
  4. Subject: [rec.games.mud]: FAQ #3/3: RWHO and "mudwho"
  5. Message-ID: <faq_rwho_766476003@math.okstate.edu>
  6. Followup-To: rec.games.mud.misc
  7. Summary: info on rwho servers, and mudwho
  8. Keywords: muds rwho mwhod mudwho
  9. Lines: 135
  10. Sender: jds@math.okstate.edu (Jennifer Smith)
  11. Supersedes: <faq_rwho_765183605@math.okstate.edu>
  12. Reply-To: jds@math.okstate.edu
  13. Organization: Oklahoma State University, Math Department
  14. References: <faq_muds_766476003@math.okstate.edu>
  15. Date: Sat, 16 Apr 1994 06:00:44 GMT
  16. Approved: news-answers-request@MIT.Edu,rgm-announce-request@glia.biostr.washington.edu
  17. Expires: Fri, 13 May 1994 06:00:03 GMT
  18. Xref: bloom-beacon.mit.edu rec.games.mud.announce:818 rec.games.mud.misc:7342 news.answers:18117 rec.answers:4917
  19.  
  20. Archive-name: games/mud-faq/part3
  21. Version: $Id: faq.rwho,v 3.1 1994/03/14 05:19:56 jds Exp $
  22.  
  23. FREQUENTLY ASKED QUESTIONS: Basic Information on RWHO and "mudwho"
  24.  
  25. This is part 3 in a 3 part series of FAQs.
  26.  
  27.  
  28. Table of Contents
  29. -----------------
  30.         1. What is RWHO?
  31.         2. How Does It All Work?
  32.         3. Where Can I Get This Stuff?
  33.         4. Where Are Some RWHO Servers?
  34.  
  35.  
  36.  
  37. 1. What is RWHO?
  38.  
  39.   RWHO stands for 'Remote WHO'.  It's a way of getting a WHO list from
  40.   a MUD, without even having to connect to that MUD at all.  Anyone
  41.   can get this output from a RWHO server (an 'mwhod'), by using straight
  42.   telnet to connect to a certain port (6889), or by using the client program
  43.   'mudwho'.  RWHO servers talk to other mwhods, passing information around,
  44.   and are talked to directly by some MUDs, receiving information from them. 
  45.   Any one mwhod keeps track of several MUDs, plus storing information passed
  46.   it from other mwhods.  Only MUDs that have the RWHO routines compiled in
  47.   will be able to send their WHO list info to a mwhod.  UnterMUDs have this
  48.   capability built in; other MUDs have to have the routines installed first.
  49.   The RWHO routines have been installed into TinyMUSH, TinyMUCK, LPMUD,
  50.   DikuMUD, and AberMUD, without encountering any difficulty.
  51.  
  52. 2. How Does It All Work?
  53.  
  54.   'mwhod' is the RWHO server that runs on a particular host and
  55.   keeps a list of known MUDs. It is initially primed with a list of "trusted"
  56.   MUDs and passwords used for authentication, and will accept information
  57.   about who is logged into those MUDs. The server also has a notion of
  58.   a "peer" server, which can transfer it (occasionally) a copy of all of
  59.   its list of who is logged on, and where. The idea is that the whole
  60.   MUDding community could probably be served pretty well by about 5 peer
  61.   mwhods that kept each other up to date about what each one is seeing.
  62.   
  63.   Communication between mwhods (and server updates sent to mwhods)
  64.   is done with UDP datagrams, since they're fast, nonblocking, and
  65.   throw-away. (RWHO information is considered to be interesting but not
  66.   vital information, if you get my drift). Each MUD server only sends
  67.   updates to a single mwhod, which may then propagate that information
  68.   to its peers. This is done within the MUD server as follows:
  69.   
  70.         - whenever the server boots, it sends a "hi there" packet to
  71.          the mwhod, telling it that it's up and running.
  72.         - whenever a player connects, it sends a "so and so is here"
  73.          packet to the mwhod, telling it that the user has connected.
  74.         - whenever a player disconnects, it sends a "so and so left"
  75.          packet to the mwhod, telling it to delete the entry.
  76.         - every so often ("so often" being defined as a time agreed
  77.          upon by the mwhod's owner, and the MUD's wizard, usually
  78.          every 5 minutes or so) the MUD sends a "hi there" packet
  79.          and a complete list of everyone that is on, just to refresh
  80.          the mwhod's idea of who is logged into that MUD.
  81.  
  82.   If a user connects to a specific port (6889) of a host machine
  83.   running an mwhod they are given a formatted dump of the mwhod's current
  84.   table of MUDs and players, and then disconnected. "mudwho" is a simple
  85.   little program that contacts an mwhod and downloads this information. 
  86.   Ideally, the functionality of "mudwho" would be built into a player's
  87.   client software, for ease of use. Two handy options can be used by 
  88.   "mudwho", if the netlag to the mwhod server isn't too bad. The options
  89.   are "-u <username>", and "-m <mudname>". If received before the timeout,
  90.   the mwhod will then only dump WHO list information for the specified
  91.   player or MUD.
  92.  
  93.   The mwhod does some clever stuff as far as eventually timing
  94.   information about of its tables - for example, if it hears absolutely
  95.   nothing from a MUD for a certain amount of time, it will mark the MUD
  96.   as down. Player entries are expired similarly. The design is based on
  97.   the idea that we'll use UDP to just fling information out and hope it
  98.   sticks, and then let the recipient clean it up, rather than to develop
  99.   a more complex protocol based on TCPs and timeouts. To prevent a packet
  100.   circular send situation, each entry that is sent is given a "generation"
  101.   number, which is incremented by one each time it is forwarded along. In
  102.   this manner, a MUD server might send a "so and so is here" (generation
  103.   zero) to its local mwhod. The local mwhod will eventually send a copy to
  104.   any peers it may have (generation one), and so forth. Part of the initial
  105.   table that an mwhod uses to establish what peers it trusts contains a
  106.   generation value, and it will neither accept nor propagate information
  107.   to a specific peer that is of a higher generation value. This way, a
  108.   "tree" of servers could theoretically be constructed, with the highest
  109.   level one having a total view of a large MudIverse.
  110.  
  111. 3. Where Can I Get This Stuff?
  112.  
  113.   The client program "mudwho" can be ftp'd from ftp.math.okstate.edu
  114.   (139.78.10.6), in pub/muds/clients.  The shar file contains both
  115.   mudwho.c and a README file, listing a few mwhod sites.  The plain "mudwho.c"
  116.   file can be found at decuac.dec.com (192.5.214.1).
  117.  
  118.   The RWHO routines can be ftp'd from decuac.dec.com (192.5.214.1),
  119.   in pub/mud.  Included is a HOW_TO file, which describes how to plug
  120.   the routines into a MUD server, and also where to ask for a mwhod to use.
  121.   
  122.   The mwhod program itself can also be found on decuac, but there is
  123.   currently little need for another one running in the USA.  There is, however,
  124.   only one running in Europe, and further expansion may need to be made in
  125.   that area. 
  126.  
  127. 4. Where Are Some RWHO Servers?
  128.  
  129.   Currently, all of these servers talk to each other, so what one knows, 
  130.   the rest will know, with the exception of the mwhod in Germany, which only
  131.   talks to the mwhod on riemann.math.okstate.edu (so only riemann has
  132.   the RWHO information from Europe currently). At any one time, there's an
  133.   average of 20 muds, of various types, talking to mwhods.
  134.  
  135. Site                         IP           Port  Admin
  136. ------------------------------------------------------------------------------
  137. riemann.math.okstate.edu     139.78.1.15  6889  jds@math.okstate.edu
  138. amber.ecst.csuchico.edu      132.241.1.43 6889  warlock@ecst.csuchico.edu
  139. nova.tat.physik
  140.   .uni-tuebingen.de          134.2.62.161 6889  gamesmgr@taurus.tat.physik
  141.                                                 .uni-tuebingen.de
  142.  
  143. ------------------------------------------------------------------------------
  144.   This posting has been generated as a public service.  If you have any
  145.   suggestions, questions, additions, comments or criticisms concerning this
  146.   posting, contact Jennifer Smith, aka Moira (jds@math.okstate.edu).
  147.   Other Frequently Asked Questions (FAQ) postings contain information 
  148.   dealing with MUDs, MUDding, clients, servers, and FTP sites.  While these
  149.   items aren't necessary, they are quite useful.  I'd also like to thank 
  150.   Marcus J Ranum (mjr@decuac.dec.com) for writing such a wonderful program
  151.   (and decent docs), and everyone else for helpful comments and suggestions. 
  152.  
  153.   The most recent versions of these FAQs are archived on ftp.math.okstate.edu
  154.   (139.78.10.6) in pub/muds/misc/mud-faq, plus on rtfm.mit.edu(18.170.0.226)
  155.   in the news.answers archives.  Have fun!  - Moira
  156. -- 
  157. Jennifer Smith
  158. jds@math.okstate.edu
  159. On MUDs: Moira, Jasra, etc.                 |    But still I fear and still
  160. Here, have a clue. Take two, they're small. | I dare not Laugh at the Madman.
  161.